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ABSTRACT 

This thesis presents the development and planning for redesigning the 
Student Record System at the Defense Language Institute, West Coast. 

The redesign is based on the INFONET system of Computer Sciences Corp- 
oration and the use of a data base system and data base language: Data 
Management Language (DML) . This system is in the process of implemen- 
tation at the Computer Systems Division of the Defense Language Institute, 
West Coast at the present time. 
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I. PROBLEM STATEMENT AND OBJECTIVES 



The problem was to re-design the data processing system at the De- 
fense Language Institute West Coast for use on the INFONET system of 
the Computer Sciences Corporation in order to make the system more re- 
sponsive to user needs. This led to the design and implementation of a 
data base system, for manipulation by non-computer personnel at DLFWC, 
which would interface with the existing data processing system. Three 
major areas of the Computer Systems Division of DLFWC were investi- 
gated. These areas are: course scheduling and management, resource 
management and student records. These systems had long turn around 
times and low through put rates. 

The computer was not used for resource management. Resource manage- 
ment which was done manually had little accuracy and was not controlled. 

Another major problem was in the student registration system at the 
school. The form the student filled out on arrival did not capture all the 
information that was required of him. This information was then hand 
punched on IBM cards and transferred to the main computer facility at the 
Naval Electronics Laboratory Center at San Diego and finally received by 
the user departments at DLI nearly a week later. This situation had an 
adverse effect on teachers during the first week of school because changes 
in student status and classes were being made. 

All grading was maintained manually as was the attendance of each 
student. This information was sent to the Computer Systems Division 
every six weeks to be entered in the files. 
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These conditions contributed to the untimeliness of many required re- 
ports, such as the registration reports and class rosters. 

Other problems arose from the fact that the present system was built 
piecemeal, each subsystem standing alone with no interface with the 
other subsystems. 

The hardware configuration also caused major problems. All master 
files were maintained on magnetic tape. Not more than ten percent of the 
records on file were updated at any one time, but since they were on tape, 
the entire file had to be passed for update. 

A committee was established to investigate these problems and ana- 
lyze and design a better system. This committee decided that a general- 
ized data base system to manipulate data concerning courses, student 
records and resources was needed. The committee wanted an interactive 
query capability with inputs from non-computer personnel at the depart- 
ment level at DLI. 

The project was initiated by making a determination of all outputs nec- 
essary to capture and store the data required to solve the problem. Sub- 
sequent efforts were made to determine which processes and systems were 
in existence and relavent to the problem at that time, and if mechanization 
of these processes was feasible. Finally, a data base system would be 
developed which would interface with other ongoing DLI systems, thereby 
expanding the existing data base and creating new areas of related information. 

Many alternative systems were considered and will be examined in the 
next section. The INFONET system, which is a subset of the Computer 
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Science Time Sharing (CSTS) system, was selected due to the existence 
of a G.S.A. contract for INFONET services, which DLI and the committee 
was not aware of at the time. Due to this factor, the scope of the prob- 
lem did not change but the selection of the system and hardware had been 
decided. This allowed DLI to concentrate on the problem of converting 
to the new system without becoming involved in the detailed analysis of 
choosing hardware and software and negotiating contracts with various 
vendors . 
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II. APPROACH 



The initial approach to designing an Automated Data Processing sys- 
tem or redesigning an existing system consists of conducting meetings 
with top management in order to determine some basic goals. What should 
be automated in the organization? This was the most significant ques- 
tion. The DLI had a computer, but the design called for the implementa- 
tion of new processing procedures. Investigation of all repetitive tasks 
was performed. In addition, chronic problem areas were investigated, 
such as the interface of the various subsystems at DLI. Along with the 
repetitive tasks were the many clerical functions that could easily be 
computerized. Lastly, it was found that response time was too long and 
that operating costs were too high. 

Next came the feasibility study of the project. A proposed schedule 
was set up with two months for overview and detailed, study of the project 
and related systems; four months for system design, data base structur- 
ing, form and report design and production; four months for program devel- 
opment and testing; and two months for the system implementation. This 
led to a target completion date of middle of fiscal year 1974. 

The feasibility study investigated the present system (discussed in 
section III) , the conceptual design of the INFONET system (discussed in 
section IV), and a quasi-economic comparison of the two systems. The 
two systems could not be accurately and objectively compared, since 
they were both under G.S.A. contracts and it became imperative (under 
orders from the Department of the Army) to implement the INFONET system. 
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It was determined that the centralized computer centers of Computer 



Sciences Corporation and the de-centralized data processing facilities 
of DLI were extremely advantageous for the Army, since records and data 
could be accessed from all parts of the country. 

The next major problem was to find a file system which would provide 
an interface with other files and which would provide retrieval of infor- 
mation from a data base quickly and easily. Four major types of files 
were investigated: sequential or serial files, partitioned files, indexed 
sequential files, and direct or random files. 

In sequential files, records are organized strictly on the basis of rel- 
ative position, usually around a logical key. Individual records cannot 
be located quickly by this method, and adding and deleting records usu- 
ally requires a complete rewrite of the file. Searches in a sequential file 
are extremely time consuming and most records are accessed each time 
the file is processed. 

The partitioned file consists of several sequential members. It con- 
tains a fixed amount of space, which is fixed at file creation, but ele- 
ments within this space may be reused. The members of this file are 
located by a directory which is organized by member name. These mem- 
bers can be added or deleted. 

The indexed sequential file combines direct access and sequential 
processing. It allows both rapid sequential access and rapid location 
of a particular record (when using disk or drum) . Records are added to a 
file in a special overflow are, either on the end of a track or on a separ- 
ate track in a disk. 
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In the direct or random file the relative position of one record to an- 
other is of little importance. However, there must be a predicatable 
relationship between the logical key for a record and its physical loca- 
tion on a disk. This is done by either having the logical key for a re- 
cord be thephysical address for that record or by using an address calcu- 
lation algorithm in connection with a directory at the beginning of a track 
on a disk with pointers to the records on that track. 

It was determined that although the indexed sequential file structure 
seemed to be the best one examined, it still lacked much of the capabili- 
ties that were required. This spurred research into a data base system 
approach. A data base is a totality of information with logical connec- 
tions and a common set of definitions . A data base system seemed to be 
an acceptable approach, since it provides a management information capa- 
bility , uses storage efficiently, eliminates redundancy in files and re- 
cords, provides better control of the data, is flexible and adaptable, 
allows less experienced programmers to use it, and is accessible by on- 
line terminals . 

Several drawbacks were found concerning data base systems. One of 
the major drawbacks is the lack of trained personnel in this area. In 
spite of the drawbacks, it was decided to implement a data base system 
using DML (Data Management Language) available through the INFONET 
system . 
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III. EXISTING SYSTEM 



The Computer Systems Division (CSD) of DLIWC had been operating 
in a timesharing mode by using a computer located at the Navy Electron- 
ics Laboratory Center (NELC) , San Diego, California. NELC utilizes an 
IBM 360/65 computer with 512 K bytes of high speed storage and 1024 K 
bytes of low speed storage. Two selector channels control the 2 314 disk 
packs and the seven magnetic tape drives. Two high speed printers were 
also available, but since DLIWC had an IBM 2780 card reader and high 
speed printer, the printers at NELC were seldom used. The operating 
system employed was the MVT version of OS/360, which provides a multi- 
programming capability of up to fifteen jobs . 

The Standardized Student Record System (SSRS) was the basis for the 
existing system. The master file of 2600 records of 300 characters each 
contained academic and personal information for the entire student body 
at DLIWC. The system also served as a basis for input to the DLI History 
File from which certain post-graduation studies were made. 

The SSRS consisted of four tapes with a son-father-grandfather backup 
file system. Student record data for this file was initiated by the comple- 
tion of the DLI registration form 90. This form was processed by optical 
scanning equipment, converted into standard card format and served as 
input, through the IBM 2780, to the computer for adding records to the 
master file. Corrections, changes, deletions and additions were processed 
against the record by using the change input forms (DLI forms 35,36, 11). 
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This master file was used while the student was enrolled, for activation 
reports and graduation rosters. Upon the graduation of a student, aca- 
demic data was placed in the record and the record was transferred to the 
Student History File by the update program, which had procedures that 
allowed for file protection. 

The system included eight basic subsystems: Active Student Records, 
Student History, Class Scheduling, Schedule Maintenance, Test Devel- 
opment, Test Scoring, Statistical Analysis , and Catalogues. These sys- 
tems were developed in a helter-skelter manner due to the urgent need for 
DLIWC to become operational on the NELC system in early 1971. Overone 
hundred sixty two programs and files had to be maintained in order to op- 
erate the existing system. This allowed for little or no interface with 
other portions of the system. 

The Standardized Student Record System had ten major programs consist- 
ing of the student input roster, recapitulation of student. input, grade sheets, 
student activation bulletins, Army Intelligence Service input roster, the 
twelve to twenty-four week projected graduation roster, Army Security 
Agency input roster, academics records class roster, division information 
roster and company "B" labels. 

There existed three major programs for the graduation reports. There 
was the Graduation Bulletin for the academic departments, the Graduation 
labels for the envelopes containing orders and papers for the graduating 
class and the Graduation Verification Roster to send to the Department 
of the Army and Service Liaison office. 



14 



Sixteen programs and files were needed to generate the output reports 
required for the different agencies connected with DLIWC. Three separ- 
ate files were used to output the required data: a master file by name, a 
master file by social security number and a master file by student class 
number. From these three files twelve general output reports were pro- 
duced: the Civilian Student Roster, Dispensary Roster, Resident Student 
Enlisted Roster, Dental Clinic Roster, Army Security Agency Student Ros- 
ter, Resident Student Officer Roster, Navy Officer and Enlisted Roster, 
Army Intelligence Service Roster, Resident Service Count, Recapitulation 
of Current Status, Educational Status Report and Six Month Projected Grad- 
uation Roster. 

It is obvious that with all these varied files and report programs many 
file maintenance routines were needed. Ten such routines were required 
in order to keep the system operational: the DLI Master file (DLIMAST) 
update, DLIMAST Tape Log, DLIMAST Edit Listing, DLI Master History 
Tape Creation, DLI Master History Tape Printout, DLI Master File first 
78 characters cut in cards, DLI History File to new tape with printout, 

DLI Master File to new tape with printout, History Duplication Elminator 
and Old History File update. 

There existed many problems with the system that was established. 
Reports were not timely; grading by daily, weekly and six week intervals 
was maintained strictly by hand; and student attendance records were 
recorded and updated by the professors before being entered on the history 
file . 
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The Standardized Student Record System had several basic problems 
which will be corrected in the proposed system discussed in a later 
section of this paper. The DLI form 90 (Student Registration) was not 
designed to capture all of the information required in each record of the 
Master File. Most of the records were hand punched and initial output 
reports were usually a week late. Grades, which were entered on a Grade 
File, were recorded by hand and inputted to the file in a make-shift manner. 

Appendix A shows the format of the forms and records that were part of 
the existing system. Comparison of these forms with those of the new 
system in a later section, show the improvement that has been made. 
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IV. INTRODUCTION TO THE INFONET SYSTEM 



INFONET is a remote computing network operated by the Computer 
Sciences Timesharing System (CSTS) operating system. It is designed 
to be used by users of all levels of proficiency in both batch or inter- 
active mode and gives the user complete flexibility in his use of files. 

The GSA contract provides DLIWC access to the INFONET communications 
in 12 Federal Data Processing Centers and the main Computer Sciences 
Center in Los Angeles. 

The CSTS (Computer Sciences Timesharing System) is designed to allow 
the user to develop and debug all programs interactively whether they are 
designed for batch use or interactive use, and batch processing can be 
initiated by a conversational terminal and the output can be directed to 
any selected terminal or printer. This is done by GPS (General Program- 
ing Subsystem) and a unified Command language which can be altered by 
the user if needed. 

The INFONET file system is device-independent, allowing programs 
to be unaware of where its files are residing, letting them be transferred 
freely from one device to another without file format change. Direct ac- 
cess storage files are not preallocated because the space is dynamically 
allocated as files are built and updated and individual files of up to one- 
quarter billion characters can be maintained. 

A. INFONET HARDWARE 

The main INFONET computer installation in Los Angeles consists of a 
UNIVAC 1108 computer and direct access mass storage is provided by a 
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multiple disk drive subsystem built by Control Data Corporation and inter- 
faced to the CPU by custom built dual controllers (see figures 1 and 2) . 
Removable disk packs allow modual expansion of storage capacity and 
protection from disk drive failures. 

INFONETs Communication network centers around Remote Communica- 
tion Cencentrators (RCC) which provides data multiplexing and error con- 
trol while relieving the central computer of most of the communications 
workload and interfacing. The use of RCC's allow new terminals, speeds, 
and disciplines to be added without changing hardware or operating sys- 
tem software configurations. 

The hardware configuration for DLIWC consists of hardware located in 
the Computer Systems Division and two remote terminals located at the 
offices of the Assistant Dean for Administration and the Systems Devel- 
opment Agency. This arrangement allows the other users to create files 
which are subsequently stored by the personnel of the Computer Systems 
Division. This file protection procedure restricts the handling of stored 
files to CSD personnel. The remote users work only on a copy of the files 
in a work area of the computer. 

The hardware at the central Computer Systems Division will consist of 
three terminals including one Optical Scanning terminal and an IBM 27 80 
high speed printer and an on-line card reader. This configuration will 
allow the generation of hard copy reports required for DLI Headquarters 
Command . 
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Figure 1 



INFONET CONFIGURATION 



INFONET CONFIGURATION 
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Figure 2 
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V. DATA MANAGEMENT LANGUAGE 



The Data Management Language (DML) is an INFONET software sys- 
tem designed to be a powerful tool in creating, updating and managing 
data bases. DML was designed for the quick implementation of data 
base applications. By using DML a user can define the structure of a 
data base, create a data base, retrieve data using either unique record 
keys or Boolean selection criteria, update a data base, generate reports, 
perform direct computation using a data base, and create application pro- 
grams and procedures so that inexperienced users can query data bases. 

Using the capability to create application programs, DML enables a 
user to store frequently used and complex data base manipulation and re- 
trieval statements . DML can be used in either the interactive terminal 
mode or through batch processing and data bases can be accessed simul- 
taneously by any number of terminals for inquiry or reporting functions. 

The DML system operates in the on-line environment of the Computer 
Science Timesharing System. The system can be used for the production 
of simple reports or for interactive inquiry for specific information. Pre- 
viously prepared DML application procedures can be used for the produc- 
tion of data bases and complex reports. This feature allows the user to 
have a minimal understanding of the operating system in order to achieve 
his goals . 

DML data bases reside on mass storage devices and consist of variable 
length records that can be accessed either by key or sequentially. Each 
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record has one key field and up to 2 50 data fields. Multiple data bases 



can be accessed concurrently through DML and external data files can be 
accessed for data base creation and maintenance. 

DML is a COBOL like language which interfaces with the COBOL used 
at DLI. Like COBOL, DML consists of operators and operands. The op- 
erators are data base file-handling commands, input/output and formatting 
commands, computational and manipulative operations, and statistical 
operators. Operands consist of names of data files or data bases, appli- 
cation procedure statement labels, constants, file elements, subelements, 
and internal and system variables. 

Two important files are data base files and data files. Data base files 
are logically related records with file element values. Each data base file 
must have a unique key element or element that enables direct access to 
any record in the data base. Three data base files may be open at any 
one time and each data base file can have up to 250 element definitions. 
The data files are used to interface with the data base files in input and 
output operations. Data files are used to input data in the batch mode 
(card input) or disk files created by DML or COBOL. In the same manner, 
data files can be output to terminals and high-speed printers. 

The operators of DML are of seven basic types: 

1. general operating commands 

2. data base file-handling commands 

3. computational and logical operators 

4. statistical operators 

5. control operators 

6. input/output and format commands 

7. utility routines 
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The specific operators for each of the seven types are shown in 
figure 3. 

A. GENERAL OPERATING COMMANDS 

The general operating commands are used to interface DML with the 
General Programming Subysystem (GPS) . The DML command requests 
the use of DML and the RUN command invokes previously prepared and 
stored DML application programs allowing inexperienced users to exe- 
cute complex procedures without extensive knowledge of the language. 

B. DATA BASE FILE HANDLING COMMANDS 

DML data base file-handling commands allow the establishment 
(creation), access or modification of a data base; partitioning a large 
data base, and closing a data base from a DML session. DECLARE and 
CREATE commands are used in establishing a data base file. In access- 
ing a data base file, the commands used are: SEARCH, MORE, FIND, 
KFIND , WHERE and KWHERE. STORE, CHANGE, REPLACE and DELETE 
are the commands used in the modification of a data base and the END 
command is used to terminate a session. 

C. COMPUTATIONAL AND LOGICAL OPERATORS 

The computational, relational and logical operators employ symbols 
which are standard for most languages with the exception of the denota- 
tions # (logical OR) 6 
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D. STATISTICAL OPERATORS 



Statistical operators are generally used in conjunction with FIND 

commands to perform specified computations and store results in user 

/ 

specified internal variables . 

E. CONTROL OPERATORS 

The control operators: assignment operator (=) , GO TO y GOSUB, RE- 
TURN, IF and STOP control the entering and exiting of subroutines, jumps 
in a program, logical if, and the cease of execution of a DML program. 

F. INPUT/OUTPUT FORMAT COMMANDS 

The INPUT/OUTPUT commands can be either formatted or non-formatted 
data. The DATA command must be used when information is inputted into 
or outputted from a specific file. COLUMNS, PAGE, SKIP and LINES com- 
mands allow the user to format OUTPUT or PRINT commands in order to 
facilitiate easy report generation. The UNPACK command allows entry 
into the elements of a record which also facilitates report generation. 

G. UTILITY ROUTINES 

DML has two built in utility routines used to enhance report genera- 
tion. The first, DMLSRT, which resides on GPS (General Programming 
Subsystem) creates a new data base and sorts the data base in either 
ascending or descending order. This new data base is independent of 
the old one and can be used for all sequential reports, inquiries, and 
updates . 



24 



The second utility program, DMLDBD, on GPS, allows the user to 
list the declaration of an existing data base file. This routine facili- 
tates formatting of application routines for report generation. 

In order to interface DML with complex application procedures and to 
prepare the data files used in the creation of DML data bases, the use 
of the GPS Editor is a necessity. The Editor is used to create, modify 
and list punctuated files. The Editor is invoked by requesting GPS and 
then using the EDIT command. The EDIT command has eleven directives 
and operators which manipulate files: 

1. COPY 

2. DISPLAY 

3. GAIN 

4. KEYS 

5. Line 

6. LIST 

7. NUMBER 

8. POST 

9. QUIT 

10. REVISE 

11. STET 

COPY is used to insert or replace a line or group of lines, in the edit 
file. DISPLAY causes specified lines to be displayed after the last edited 
line in the file. GAIN causes the increment in line numbers to be changed. 
The KEYS directive displays the first and last line number in the file being 
edited. The Line number starts automatic line numbering while in the edit 
mode. It is also used to enter a file being edited at a specific line number. 
LIST permits the user to list specified lines or range of lines to the output 
file. NUMBER renumbers all or a specified group of lines in the file being 
edited. The POST directive applies the updates to the file being edited 
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and stores the updated file. The QUIT directive terminates the GPS 
Editor and retains the edited file. REVISE scans the specified lines for 
a specified search string and applies certain editing operators to each 
line fournd. Finally, the STET directive discards all updates made since 
the last POST directive. 

The following figures show a sample of DML's use. The first one 
shows the creation of a data base on an INFONET terminal. This data 
base was taken directly from the existing SSRS. The three queries that 
follow as for: first, allof the Colonels at DLIWC (figure 5) , second, 
all of the females at DLIWC between the ages of twenty-four and 
twenty-seven (figure 5), and third, all of the females at DLIWC under 
the age of twenty (figure 6) . 
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Figure 3 



DML OPERATORS 



1. GENERAL OPERATING COMMANDS 



DML 

RUN 

| 

2 . DATA BASE FILE- HANDLING COMMANDS 



DECLARE 

CREATE 

STORE 

SEARCH 

CHANGE 

REPLACE 

FIND, KFIND, WHERE, KWHERE 

DELETE 

MORE 

END 

3. COMPUTATIONAL and LOGICAL OPERATORS 

+ — * / ** 

' / / / / / 

<, =,> 

& (logical AND) 

# (logical OR) 

4. STATISTICAL OPERATORS 

COUNT 

SUM 

MAX 

SUMQ 

MIN 



5. CONTROL OPERATORS 



IF 

GOSUB 
GO TO 
ELSE 
RETURN 
STOP 
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Figure 3 



DML OPERATORS 



6. I/O and FORMAT COMMANDS 

DATA 

DELIMIT 

FORMAT 

INPUT 

OUTPUT, PRING 

COLUMNS 

UNPACK 

PAGE 

SKIP 

LI NES 



7 . UTILITY ROUTINES 



DMLDBD 

DMLSRT 
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Figure 4 



EXAMPLE DATA BASE PROGRAM 
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Figure 5 



DATA BASE QUERIES 
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Figure 6 



Date Base Queries 
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VI. IMPLEMENTATION 



The new Student Record System contains four major files: the Student 
Masterfile, the History File, and two transaction temporary files used in 
updating and entering new students . 

The Student Masterfile consists of approximately 3000 records, each 
record containing 2 50 characters. This Masterfile is an indexed sequen- 
tial file keyed on the Social Security Number of the student. The file is 
updated sequentially and specified records can be accessed directly . It 
is written using standard COBOL in order to comply with the Department 
of the Army requirements . 

A copy of the Masterfile will be put on DML daily for user access. This 
arrangement not only prevents file alteration by inexperienced users, but 
also reduces the permanent disk storage space required to maintain twin 
files. The application programs written in DML will allow inexperienced 
users (such as Personnel Headquarters Company) to add, change and de- 
lete information concerning a student, without the user having extensive 
knowledge of COBOL or the system operation. Computer System Division 
personnel can effect the changes to the Masterfile at the end of the day 
by copying the new masterfile back into COBOL format. INFONET's GPS 
Editor will be used for this purpose. 

Appendix B shows the flow charts and record layouts for the proposed 
systems . 
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A. IMPLEMENTATION SCHEDULE 



Implementation of the new system is basically an eleven step operation. 
The first and most important step is the conversion of the existing system 
at NELC, San Diego, to the INFONET system at Los Angeles, This con- 
sists of making the tapes at NELC compatible with Computer Science Corp- 
oration's hardware (the INFONET system). 

The second step requires parallel operation between the old and new 
systems. There is a need to run both systems (NELC and INFONET) in par- 
allel for approximately two weeks. This is a safety check to ensure that no 
information has been lost in the transfer of tapes from NELC to INFONET. 

The third step is to discontinue the NELC system and to use INFONET 
exclusively, producing all present output at the local user high speed IN- 
FONET terminal. 

Step four is the redesign of input procedures for remote input and update 
by inexperienced users. 

Step five involves user training on those remote INFONET terminals which 
are not located at the Computer Systems Division. 

Step six is the redesign of the Form 90 (student input form) and the grade, 
attendance and file updating forms. These will all be on an optical scan 
form; the scanned data will be transmitted to the computer. 

Step seven is the redesign of the student records, historical records, and 
the masterfile and historical file. 
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Step eight is the writing and testing of the update, file handling, re- 
porting and input programs and the checking of the information flow for 
the entire system. 

Step nine is the final test of the new system. This should be completed 
approximately by mid-fiscal year 1974. 

Step ten is user training for the non-computer personnel at DLrwC. 

This training will be conducted on a continuing basis due to the turnover 
in personnel . 

The final step is to monitor and modify the system as new requirements 
arise . 

At the present time step eight is almost completed and the planning for 
step nine is being formulated. 
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VII. CONCULSIONS 



The new system is the first one implemented at DLI with sufficient lead 
time for study and implementation on a set schedule. The target comple- 
tion date of mid-fiscal year 1974 will probably be met. 

The most important advantage of the new system is the elimination of 
redundant information. This lowers cost due to the efficient use of stor- 
age. There is much shorter response time for transactions due to the on- 
line operation of the INFONET system. New information can be added to 
the Student Records as needed. The GPS Editor and DML provide for ease 
of processing and report generation. Much of the work now done by CSD 
personnel can be done by non-computer personnel at the Headquarters de- 
partments and the Systems Development Agency. The query feature (seen 
in figures 5 and 6) represents a new capability for DLI. It eliminates many 
one-time report programs that were needed for statistical studies, thus 
freeing the system programmers for other duties. 

The new system is not without problems and drawbacks. The data base 
system is conceptually advanced and therefore there exists a lack of well- 
trained personnel in this area. It is impossible to emulate the existing 
system with any new system due to the difference In file structures. This 
may cause problems when a back up system is required during the conversion 
period. The training of CSD and DLI personnel will be both time-consuming 
and difficult because there is no training syllabus and the use of the system 
is being learned through actual operation. 
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Despite the problems and drawbacks of the new system, it will be a 



great improvement over the existing system and it will allow the Depart- 
ment of the Army to have a standardized system in all of the Defense 
Language Institutes. 

Future work is planned in connecting all installations of the Defense 
Language Institute through the INFONET system, thus allowing direct 
communications and queries among all units and giving better control 
to the Commander of DLI. 
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APPENDIX A 



Existing System Flow Charts, Record Layouts and Forms 

1. Existing System Flow Chart 

Figure 7 shows the flow chart of the existing system with the son - 
father-grandfather back up file system. After card images are cut from 
the optical scanner, every form including the rough forms are filed and 
kept by the respective departments. As can be seen, there are five 
tapes kept in order to produce the reports needed for DLIWC. 

2. Student Master Record Layout 

Figure 8 shows the record layout of the existing system. It contains 
150 characters which captured the data required with 14 characters left 
for expansion . 

3. Student Registration, Input and Change Forms 

Figures 9 through 13 show the existing registration forms needed to add 
the information not included on the student registration forms. Forms 11, 
12, and 13 were hand punched by CSD personnel and separate programs 
were needed to effect the changes to the respective records. 



37 



TA*T 



Figure 7 

Existing System Flow Chart 
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Figure 8 



Old Student Master Record Layout 
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Figure 9 



Old Student Registration Form (Form 90) 
(Side 1) 
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Figure 10 



Old Student Registration Form (Form 90) 
(Side 2) 






DLIWC Form 90 1 June 70 (DLlWC Form- 90 dtd 1 Nov 67 - is ob»oU**) oc 749 s 
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WITH VOU DURING TOUR 
AT DU? 



DU STUDENT FILE UPDATE INPUT SHEET 



Figure 11 



Student Record File Change Input Sheet (DLI Form 11) 
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STUDEMT RECORD - FILE CHANGE INPUT SHEET 



Figure 12 
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Figure 13 



Student Record File Change Sheet, 

SSN or Closing Date (DLI form 36) 

STUDENT RECORD • FILE CHANGE INPUT SHEET 
CHANGE CODES "6" & "7" ONLY 

I CODES: 

REPORT TYPE 

6 - CHANGE SSAN OF RECORD ONLY 

7 • CHANGE INPUT AND/OR CLOSING DATES REPORT DATE 



CLASS NO OF RECORD NEW DATES 




To change a students SSAN (code 6), enter code ”6” in col 1 ("ACT CD” - 
action code); enter the erroneous SSAN as it appears in the report in 
the "SSAN OF RFCORD" block (cols 27-35); enter the correct SSAN in the 
"NFW SSAN" block (cols 36-44). When a SSAN change has been made to a 
record, no other changes are permitted during an update cycle. 



To enter or change input/closing dates (code 7), enter code "7" in col 1 
(ACT CD - action code); enter the class number to which the changes 
are to be made in the "CLASS NO OF RECORD" block (cols 2-12); enter 
the new input and/or closing dates as they should appear in the "NEW 
DATES” blocks. 
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APPENDIX B 



New System Flow Charts, Record Layouts and Forms 

1. New System Flow Chart 

The new system eliminates the need for the backup file system used 
in the old system. By comparing flow charts of both systems it can be 
seen that there is no need to keep extraneous files of IBM cards. 

Most of the changes and updates are effected through on-line terminals 
without the need for key punching many extra change cards. Interactive 
queries eliminate the need for many programs needed to generate reports. 

All transactions in the upper two-thirds of this flow chart are executed 
by non-computer personnel allowing the CSD personnel time to organize 
the remaining system. 

Five permanent files are kept in reserve in the event that some unfor- 
seen mishap may occur. This allows almost total recovery of all systems 
within a twenty-four hour period. 

The CSD personnel only have access to the actual master file as can 
be seen in the flow chart, insuring integrity of the data stored. 

2. New Student Master Record Layout 

The New Student Master Record layout captures much more information 
than the old system , as the old system allowed 14 characters for expan- 
sion. The history file allows CSD personnel to trace a student that has 
changed curricula or if he has been turned back or forward. 



45 



3. New Student Input and Grade Sheets 



The New Student Registration forms (figures 14 through 18) capture 
more information than the old ones, and conform to the Department of 
Army standards. The new grade sheet frees the professors, as well as 
some of the CSD personnel from many man-hours of hand compilations. 
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Figure 14 



New Student Registration and Update Flow Chart 
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Figure 15 

New Student Master Record Layout 
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EDPM RECORD LAYOUT 



Figure 16 



New Student History Record Layout 
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Figure 17 




New Student Registration Form (Form 90) 

(Side 1) 
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Figure 18 



New Student Registration Form (Form 90) 
(Side 2) 
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Figure 19 
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